Planète Warez

=> Article complet : nextinpact.com <=

Après les principaux systèmes de fichiers trouvés chez Microsoft, Apple et dans le monde Linux, nous nous penchons sur ZFS. Développé initialement par Sun, on le trouve dans plusieurs UNIX, quelques distributions, certaines gammes de NAS et même dans macOS pendant un temps. Ses caractéristiques sont nombreuses.

Alors que tous les noms de systèmes de fichiers sont composés généralement d’un sigle ayant un sens, ZFS n’en a pas particulièrement. Le « Z » renvoie, selon les personnes qui en parlent, à plusieurs significations, notamment zettabyte (zettaoctet) ou comme dernière lettre de l’alphabet, soulignant l’idée qu’il serait en quelque sorte l’aboutissement de ce que l’on peut faire de mieux dans le domaine.

Parmi tous les systèmes de fichiers déjà vus, ZFS est l’un des plus récents, avec APFS. Son développement a débuté en 2001. Il a été présenté et annoncé par Sun pour septembre 2004, mais il est arrivé six mois plus tard, intégré à Solaris, l’UNIX maison, puis dans OpenSolaris à la fin de la même année.

Dès le départ, ses caractéristiques ont fait de ZFS un système de fichiers à part. Il pourrait techniquement être la réponse à bien des problématiques de stockage, mais son fonctionnement particulier l’a réservé à certains scénarios. Des décisions justifiées ?

Lire notre dossier sur les systèmes de fichiers :

| Qu’est-ce qu’un système de fichiers ? | Systèmes de fichiers : FAT12 à 32 et exFAT, conçus pour le grand public | Systèmes de fichiers : NTFS et ReFS, pensés d’abord pour l’entreprise | Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple | Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux ZFS, un système de fichiers hors normes

Les caractéristiques de ZFS sont peu communes. Dans les articles précédents, vous vous souvenez peut-être que l’arrivée du 64 bits avait profondément modifié les capacités des systèmes de fichiers concernés, comme dans NTFS et ext4. Dans le cas de ZFS, on parle de 128 bits.

Techniquement, la taille maximale des volumes et des fichiers est de 16 Eo, soit 16 millions de To. Un volume peut embarquer 2⁴⁸ fichiers, soit plus de 280 millions de milliards, ce qui correspond également au nombre maximal dans un répertoire. Il n’y a virtuellement aucune limite au nombre de fichiers qu’un volume peut ainsi stocker.

Des chiffres si élevés qu’ils ont fait dire au concepteur de ZFS, Jeff Bonwick, que « remplir en totalité un espace de stockage 128 bits consommerait, littéralement, plus d’énergie que de faire bouillir les océans ». Une phrase et une explication restées célèbres.

Comme on peut s’en douter, ZFS gère les noms longs (255 caractères). Pensé avant tout pour le monde UNIX, il reprend les autorisations POSIX (comme ext4 et Btrfs), auxquelles il ajoute les ACL (NFSv4). La hiérarchie de ZFS est en arbre B, comme la plupart des systèmes de fichiers modernes.

Bien que la taille des blocs soit par défaut de 128 ko, elle est en fait variable. Elle peut être adaptée selon les besoins au sein d’un même volume, que ce soit par l’administrateur ou par des processus automatisés. En cas de compression des données, elle est ainsi automatiquement activée.

Des caractéristiques bien spécifiques

L’approche retenue dès le départ tranche avec ce que l’on a pu voir jusqu’ici. ZFS virtualise partiellement la gestion du stockage, notamment celle des disques, ce que l’on peut rapprocher du fonctionnement des volumes logiques, que l’on retrouve par exemple dans APFS. Dans ZFS, il s’agit du Volume Manager, qui ajoute une couche d’abstraction intermédiaire entre les disques et le système de fichiers, donc avec le système d’exploitation. On parle ainsi parfois de ZFS comme d’une plateforme, car il reprend à son compte des fonctions trouvées habituellement dans le système d’exploitation lui-même.

Ce dernier verra ainsi des volumes mis à disposition depuis le Storage Pool. C’est à l’administrateur de déterminer quels vont être les besoins de stockage pour configurer des vdev (virtual device, ou appareil virtuel), c’est-à-dire des agrégats de disques ou de partitions. Chaque vdev peut être configuré avec ou sans redondance des données (choix du niveau de RAID) et selon des critères de performances spécifiques.

La gestion des vdev est souple, puisqu’ils peuvent être reconfigurés. On peut ainsi modifier le nombre de disques ou de partitions dans chaque vdev, augmenter ou diminuer sa capacité en ajoutant ou supprimant des disques, on peut déclarer un ou plusieurs disques en spare (redondance) dans chaque pool, etc.

Dans la gestion de l’ensemble, on trouve deux commandes essentielles. La première, zpool s’occupe des pools (agrégats). La seconde, zfs, gère les volumes et les datasets. Par exemple, si l’on souhaite créer un agrégat « nxi » de huit disques (nommés de a à h), dont deux utilisés en redondance, la commande est la suivante :

zpool create nxi raidz2 sd[abcdefgh]

ici, raidz2 est le type de RAID choisi pour établir la redondance. Avant d’aller plus loin, il faut donc aborder la manière dont ZFS s’occupe de l’intégrité des données.

OpenZFS

Crédits : GT-ZFS

Intégrité des données : c’est parti

C’est l’une des fonctions principales de ZFS : protéger l’intégrité des données. Des caractéristiques qui l’ont rendu populaire notamment auprès de certains constructeurs de NAS.

Premièrement, ZFS fait une utilisation différente des sommes de contrôle (checksum) en SHA-256. Comme dans Btrfs, elles sont utilisées aussi bien pour les données que les métadonnées. Mais au lieu d’être stockée dans le bloc de données concerné, une somme sera stockée dans le pointeur de ce bloc (bloc parent). Ce fonctionnement est répliqué dans l’intégralité de la hiérarchie du système de fichiers.

Ensuite, ZFS fonctionne – sans surprise cette fois – sur la base du copy-on-write. Comme nous l’avons expliqué plusieurs fois, cela signifie que les modifications sur des fichiers sont faites sur des copies de ces derniers, plutôt que sur les données originales. Ce qui signifie une augmentation de l’espace requis, mais pérennise les informations, puisqu’une opération échouée pourra être retentée ou des données pourront être restaurées.

Ce mécanisme est à la base des clones et snapshots, exactement comme dans Btrfs. Dans ZFS, on peut virtuellement créer autant d’instantanés que l’on souhaite, puisque leur nombre maximal est égal à celui du nombre maximal de fichiers dans un volume, soit 2⁴⁸. Ce fonctionnement peut être automatisé pour que ZFS crée de lui-même des snapshots ou des clones (les premiers sont en lecture seule, les seconds permettent l’écriture) à intervalles réguliers, avec suppression ou non des anciens.

ZFS a ses solutions RAID bien à lui

La gestion des modes RAID dans ZFS est particulière. Plutôt que d’employer des solutions matérielles, il est conseillé de laisser faire ZFS, qui a son propre fonctionnement logiciel.

ZFS peut utiliser les modes RAID classiques, mais on leur préfèrera RAID-Z, spécifique au système de fichiers. Semblable au RAID-5 (même schéma de parité), il tolère donc la panne d’un disque. Il dispose cependant d’un gros avantage sur son modèle : il permet d’éviter les trous d’écriture.

| siteStockage : c’est quoi un RAID et comment ça marche | Stockage : on grimpe d’un cran avec les RAID 6, 10, 50, 60…

Dans une configuration RAID-Z, ZFS se sert de la copie sur écriture pour ajouter les nouvelles données aux côtés des anciennes, sans réécrire sur ces dernières. En outre, tout fichier, quelle que soit sa taille, a sa propre bande (full-strip, entrelacement total). En configuration RAID-Z, la séquence habituelle lecture-modification-écriture n’est pas utile. En cas de reconstruction, ZFS parcourt les métadonnées, une opération rendue possible car système de fichiers et matrice RAID se confondent, ZFS ayant une vue intégrée des vues logique et physique. Chaque bloc de données est alors validé par sa somme de contrôle.

Les checksums sont également utilisées pour effectuer de la « guérison automatique », quand des corruptions silencieuses de données se sont installées. Pour y remédier, ZFS compare chaque bloc lu à sa somme de contrôle. Si la réponse n’est pas bonne, le système de fichiers va lire les informations de parité correspondantes et répare les données. Une fois corrigées, elles sont envoyées au processus qui en a fait la demande.

Pour reprendre la commande donnée plus haut en exemple, raidz2 renvoie simplement à la configuration RAID-Z2, équivalente au RAID 6. Il existe une variante Z3, tolérant la panne de trois disques au sein d’une configuration RAID. RAID-Z supporte également le striping simple (RAID 0) et le mirroring (RAID 1).

À noter qu’une autre capacité est en cours de déploiement, après des années de travail : Raid-Z Expansion. Particulièrement attendue, elle permet d’ajouter un disque à une configuration RAID-Z déjà en place, opération impossible actuellement. Cette technologie fonctionne avec les configurations Z1, Z2 et Z3. La fonction est très récente. Elle est par exemple présente dans QuTS hero 5.1 (QNAP), sorti il y a un mois.

Pour les personnes comprenant bien l’anglais (ou sachant lire très rapidement les sous-titres sur YouTube), la chaine Lawrence Systems avait publié plusieurs vidéos sur ZFS, dont une portant sur la configuration des pools de stockage ZFS et de ses modes RAID-Z :

Des fonctions multiples et des caches à gogo

[…]

Source et suite : nextinpact.com

=> Article complet : nextinpact.com <=

Bon alors : quand ?

Après plusieurs articles sur la FAT32, NTFS, HFS+ ou encore APFS, il est temps de se tourner vers l’univers Linux, et plus particulièrement les deux systèmes de fichiers que l’on y trouve le plus souvent : ext4 et Btrfs. Ils se côtoient souvent, mais leur fonctionnement est très différent.

Lire notre dossier sur les systèmes de fichiers :

| Qu’est-ce qu’un système de fichiers ? | Systèmes de fichiers : FAT12 à 32 et exFAT, conçus pour le grand public | Systèmes de fichiers : NTFS et ReFS, pensés d’abord pour l’entreprise | Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple | Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux

Dans l’univers Linux, l’immense majorité des distributions se sert du même système de fichiers depuis longtemps : ext4. Le chiffre fait référence à la version. Il s’agit de la quatrième itération, même si l’on ne parlait pas vraiment à l’origine de « version » à proprement parler.

De nombreux utilisateurs francophones ignorent peut-être que la toute première version d’ext a été développée par un Français : Rémy Card. Docteur en informatique et actuellement responsable du pôle « Exploitation et Infrastructures » de la DSI de la Sorbonne, il a développé ce système de fichiers pour dépasser les limitations imposées par Minix fs, lui-même une version simplifiée du système de fichiers Unix. Parmi ces limites, on trouvait notamment une limite de 64 Mo pour la taille des partitions, ou encore des noms de fichiers ne pouvant pas dépasser 14 caractères.

Le système ext – extended file system – est intégré pour la première fois dans la version 0.96c du noyau Linux en 1992. Parmi ses apports, des partitions et des fichiers pouvant grimper jusqu’à 2 Go, ainsi que des noms de fichiers jusqu’à 255 caractères. Il garde la sémantique Unix et les bases posées précédemment, notamment les inodes.

Ces derniers sont centraux dans l’univers UNIX/Linux et étaient déjà présents dans Minix. Un inode est une structure contenant la description d’un fichier : son type, les droits d’accès, les propriétaires, les horodatages, la taille ainsi que des pointeurs vers des blocs de données. Toutes les adresses de blocs d’un fichier sont contenues dans son inode. Aussi, lorsqu’une opération d’entrée/sortie sur un fichier est demandée par l’utilisateur, le noyau convertit la demande en numéro inode, lui-même permettant ensuite d’accéder à tous les blocs du fichier.

Chaque dossier contient la liste des inodes des fichiers qu’il contient, selon le modèle suivant :

inode

Pour autant, il ne va pas rester en place bien longtemps, ext2 étant proposé dès l’année suivante.

Cette évolution du premier ext vient en corriger les principaux défauts et étendre ses capacités. Alors que la taille des partitions avait fait un bond avec ext, ext2 propulse cette limite à 4 To (théoriquement jusqu’à 32 To). Si la taille maximale des fichiers n’évolue pas dans un premier temps (2 Go), elle le fera au cours des années suivantes, pouvant grimper jusqu’à 2 To.

Lorsque ext3 apparait en 2001, il introduit un apport majeur : la journalisation. Avec ext2 en effet, en cas de corruption de la structure des données (suite par exemple à une extinction mal faite de l’ordinateur), l’outil fsck (file system check) pouvait prendre beaucoup de temps à faire son travail.

Cette journalisation, contrairement à celle d’APFS par exemple, est totale. Elle concerne aussi bien les données que les métadonnées. L’idée générale reste cependant la même : les données et métadonnées sont entreposées dans une zone spécifique du disque, et ne sont intégrées dans la structure principale qu’à l’instant où le système de fichiers reçoit la confirmation que les informations ont été correctement écrites. Le journal est ensuite mis à jour. Au démarrage suivant, ce dernier sera analysé à la recherche d’opérations non terminées, qui seront alors répercutées si aucune erreur n’a été rencontrée.

En revanche, et comme on s’en doute venant d’un mécanisme pensé pour la fiabilité, la journalisation a un impact négatif sur les performances en écriture. Initialement, on pouvait d’ailleurs la paramétrer selon trois paliers, du plus performant au plus sécurisé. Il était également possible de la désactiver, auquel cas la partition fonctionnait comme ext2.

ext4 l’omniprésent

L’arrivée d’ext4 en version stable le 24 décembre 2008 est un tournant majeur pour les systèmes de fichiers sous Linux. Ironie de l’histoire, il n’était prévu que comme une solution temporaire en attendant l’arrivée d’un système de fichiers plus moderne, à l’instar de Btrfs. Pourtant, 15 ans plus tard, il est toujours là, qui plus est sur pratiquement toutes les distributions Linux. Il n’est plus porté par Rémy Card.

Les caractéristiques principales d’ext4 sont celles d’un système de fichiers tout ce qu’il y a de plus moderne. Les partitions peuvent grimper jusqu’à 1 Eo (un million de To), et les fichiers jusqu’à 16 To. Ces derniers peuvent être 4 milliards par volume. La limite de sous-dossiers passe également de 32 000 dans ext3 à 64 000. Les inodes voient leur taille passer à 256 octets (contre 128 pour ext3) et les horodatages abandonnent les secondes pour les nanosecondes.

Les extents, petite révolution en leur temps

Surtout, ext4 apporte plusieurs évolutions importantes, dont la principale est le mécanisme d’extent. Pour le comprendre, il faut se pencher un instant sur la manière dont un système de fichiers alloue l’espace aux données. ext2 et ext3 proposaient des schémas de mappage de blocs direct, indirect, double indirect et triple indirect. Sans plonger dans les détails, retenez que ces solutions sont très adaptées pour de nombreux petits fichiers, mais pas pour les gros. Avec ces derniers, ces schémas créent un grand nombre de mappages, réduisant les performances générales, surtout lors d’opérations comme la recherche ou l’effacement de données.

De son côté, un extent est défini par une séquence contiguë de blocs physiques. La création d’un fichier entraine celle d’un extent. Si le fichier est amené à grossir, les données ultérieures sont simplement inscrites à la suite de celles existantes au sein du même extent. Quand le fichier devient volumineux, plusieurs extents sont utilisés. L’inode d’un fichier peut stocker jusqu’à quatre extents, après quoi le reste est stocké dans un arbre H (similaire à l’arbre B vu dans ce précédent article). Les blocs étant contigus, les extents réduisent fortement la fragmentation et augmentent les performances vis-à-vis d’ext3. Des intentions confirmées dès décembre 2008 par Phoronix dans une série de benchmarks. Précisons que les extents étaient une option au début d’ext4, mais qu’ils sont devenus activés par défaut avec le noyau Linux 2.6.23.

Souplesse dans l’allocation des blocs

Cette hausse de performances est également alimentée par plusieurs capacités d’allocation, comme le multi-blocs. Si ext3 allouait les blocs un par un, ext4 peut le faire pour de multiples blocs en une seule opération, diminuant la charge du processeur et la quantité de mémoire vive utilisée. ext4 peut également faire de l’allocation différée, aussi appelée allocation à la volée. Si une opération écrit des données sans les allouer d’une seule traite, elles seront stockées dans un cache. Quand les tâches d’écriture sont terminées, le cache est vidé (allocate-on-flush) et les données sont allouées dans un extent. Ces deux types d’allocation réduisent elles aussi la fragmentation.

ext4 peut aussi faire de la préallocation persistante. Elle reprend les mêmes avantages sur la fragmentation que les autres, mais permet en plus aux applications de s’assurer que suffisamment d’espace est disponible avant d’écrire des données. Le mécanisme convient très bien par exemple aux bases de données ou aux processus chargés de diffuser du contenu en continu.

Notez que les extents ne sont pas une capacité unique d’ext4. Ce mécanisme d’allocation est par exemple présent dans NTFS chez Microsoft, dans HFS+ et APFS chez Apple, dans le HPFS d’OS/2, le BFS de BeOS ou encore dans des systèmes de fichiers plus récents comme Btrfs. Par ailleurs, si les systèmes de fichiers ext ont réduit la fragmentation version après version, ils ne l’ont pas totalement supprimée. Dans ext4, il existe un outil, e4defrag, dédié à cette tâche, capable d’agir aussi bien sur un fichier spécifique qu’un dossier ou un volume. Comme pour NTFS, le passage aux SSD met fin au problème.

Fiable et éprouvé, en attendant « mieux »

Outre ces aspects, ext4 gère d’autres caractéristiques, comme une double compatibilité ascendante/descendante avec les versions antérieures du système de fichiers (bien que plus limitée avec l’activation par défaut des extents), les attributs étendus (xattr), les quotas et leur journalisation (plus besoin des longues vérifications de leur cohérence), le chiffrement des données (depuis le noyau Linux 4.1) ou encore, bien sûr, la gestion des droits.

Une précision enfin sur l’accès depuis les autres plateformes. Dans l’absolu, il est possible de lire, voire d’écrire des données sur une partition ext4 depuis Windows ou macOS, mais pas sans utiliser un outil tiers, qu’ils soient libres (ext2read, LinuxReader, etx4fuse…) ou payants, comme les produits vendus par Paragon.

Aujourd’hui, ext4 est donc omniprésent. Peu de distributions Linux se servent d’autre chose, l’un des cas les plus emblématiques étant Fedora, dont la version 33 a adopté Btrfs pour les nouveaux volumes formatés par une installation neuve du système. Mais puisque l’on parle justement de Btrfs, pourquoi ce système de fichiers, en version stable depuis longtemps, n’est-il pas encore celui fourni par défaut sur les autres systèmes ? Nous allons nous pencher sur la question.

Btrfs, un gros projet

Parlons maintenant du système de fichiers qui doit prendre le relai, tout du moins dans une partie des distributions Linux. Btrfs est loin d’être un projet neuf, puisque la première version stable dans le noyau Linux 3.10 est sortie le 29 juillet 2013 (oui, Btrfs fête ses dix ans demain). Avant cette étape, il a passé plus de quatre ans en statut instable, après son arrivée dans le noyau Linux 2.6.29. Une gestation assez longue, dont on pourrait dire qu’elle n’est pas tout à fait terminée, tant Btrfs met du temps à parvenir jusque dans les installations par défaut.

Btrfs est initialement un projet commun de plusieurs entreprises, dont Fujitsu, Intel, Oracle, Red Hat (qui depuis s’est retiré) ou encore SUSE. Développé en open source (licence GPL), il tient son nom de l’arbre B (dont nous avons déjà parlé dans notre article sur NTFS) : B-tree file system, que l’on prononce « ButterFS ». Ses caractéristiques de base sont clairement modernes : 16 Eo de taille maximale pour les volumes et les fichiers, 2^64 fichiers possibles par volume, noms jusqu’à 255 caractères, attributs POSIX et étendus, reprise des extents…

La protection et l’intégrité des données avant tout

[…]

Source et suite : nextinpact.com

=> Article complet : nextinpact.com <=

Après les systèmes de fichiers chez Microsoft, penchons-nous maintenant sur ce que propose Apple. Depuis plusieurs années, APFS règne en maître. Mais pendant une grande partie de l’histoire de l’entreprise, ce sont HFS et ses évolutions qui ont accompagné tous les produits, même les portables.

Le tout premier système de fichiers chez Apple se nomme Macintosh File System et est arrivé en 1984. À la manière de la première FAT chez Microsoft, MFS était pensé pour les disquettes (de 400 ko) utilisées avec les premiers Macintosh de l’entreprise, d’où le nom. Bien que MFS fut utilisé avec certains disques durs tiers, ses limitations étaient nombreuses : taille maximale de 20 Mo pour une partition, aucune arborescence pour les dossiers, maximum de 4 094 fichiers par volume, etc.

L’année suivante, pour accompagner le tout premier disque dur maison (Hard Disk 20), Apple lance HFS, pour Hierarchical File System. Il était en effet crucial de trouver une autre manière d’organiser les données, car les informations sur le contenu d’un volume étaient stockées dans un unique fichier. En cas de recherche, il fallait lire l’ensemble du fichier jusqu’à trouver l’information souhaitée. Ce comportement ne posait pas de problème sur des disquettes, mais est vite devenu un gros problème avec les disques durs et leurs milliers de fichiers.

Lire notre dossier sur les systèmes de fichiers :

| Qu’est-ce qu’un système de fichiers ? | Systèmes de fichiers : FAT12 à 32 et exFAT, conçus pour le grand public | Systèmes de fichiers : NTFS et ReFS, pensés d’abord pour l’entreprise | Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple | Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux HFS, le début de l’aventure

HFS reprend certaines caractéristiques de MFS, notamment les « forks » qui permettent un stockage différencié du code source des fichiers et de leurs ressources, comme les icônes ou les données de traduction. La plupart des aspects sont cependant largement transformés.

Un volume formaté avec HFS divise l’espace en blocs de 512 octets minimum. Les deux premiers (0 et 1) sont réservés au démarrage, le troisième (2) au Master Directory Block, qui contient de nombreuses informations sur les données présentes dans le volume, comme l’horodatage des créations de fichiers. Notez qu’une copie de ce bloc existait dans l’avant-dernier bloc du volume, pour autoriser les services à accéder à ces informations si le MDB était verrouillé pour mise à jour des informations.

La table des fichiers est remplacée par le Catalog File, qui utilise une structure en arbre B, dont nous avons parlé dans notre article sur NTFS. Dans ce catalogue, tous les fichiers et dossiers disposent d’un identifiant unique nommé CNID (Catalogue Node ID) associés à leur nom.

La recherche est bien plus rapide, même si HFS comporte des limites, notamment le maximum de 65 535 fichiers par le volume, inhérent aux 16 bits de l’adressage. Ce qui a rapidement posé problème avec les disques durs plus gros, puisque les volumes étaient toujours découpés en 65 535 blocs, dont la taille augmentait mécaniquement. Avec un disque de 1 Go par exemple, la taille des blocs grimpait à 16 ko, à une époque où les petits fichiers étaient très nombreux. Il était donc recommandé de découper l’espace en plusieurs volumes pour faire chuter la taille des blocs.

Le Catalog File fait en outre chuter les performances quand le système d’exploitation permet le multitâche, un seul processus pouvant modifier le fichier à la fois, créant parfois des embouteillages. En revanche, HFS n’est plus un système de fichiers « plat » : il autorise la création de dossiers et donc la hiérarchisation des données, expliquant son nom.

Mac OS 7.5

HFS a évolué peu à peu avec le temps, mais il lui est resté d’importantes limitations liées à son âge, comme des fichiers ne pouvant dépasser les 2 Go, sauf avec Mac OS 7.5 qui autorisait des fichiers de 4 Go. Mais ces derniers ne pouvaient être utilisés que sur des machines avec au moins la même version du système, limitant leur compatibilité. HFS a également atteint un maximum de 2 To pour les volumes. Quant aux noms de fichiers, même s’ils pouvaient théoriquement gérer 255 caractères, ils ne pouvaient en utiliser que 31 dans la pratique.

Les bons services de HFS vont durer un bon moment, jusqu’à l’arrivée de HFS+ en 1998. Il restera cependant géré pendant de nombreuses années, puisque son retrait effectif n’a été fait que dans macOS 10.15 (Catalina), il y a trois ans à peine.

HFS+, une petite révolution chez Apple

HFS+ – nommé aussi HFS Plus ou HFS Extended, ou Mac OS Étendu dans les outils de formatage sur Mac – débarque avec Mac OS 8.1. On est encore loin de la révolution (voir notre article) de Mac OS X, mais il était plus que temps de proposer une solution moderne au stockage sur les Mac. Il va être largement utilisé pendant presque 20 ans, et pas seulement sur les Mac.

La plupart des caractéristiques du HFS premier du nom sont toujours là, comme les blocs de 512 octets, mais presque tous les aspects en sont améliorés. Le 16 bits laisse ainsi place au 32 bits pour les adresses des blocs, faisant exploser les précédentes limites : des volumes et fichiers jusqu’à 8 Eo, et plus de 4 millions de fichiers par volume. De quoi voir venir, surtout à la fin des années 90. Même traitement pour le nombre de blocs par volume, lui aussi à plus de 4 millions, mettant fin à une taille variable selon celle du volume.

En outre, le format des noms passe à UTF-16 et Unicode, permettant cette fois d’exploiter la totalité des 255 caractères, sans restriction sur ces derniers.

Certaines capacités de HFS+ ne vont arriver qu’avec le temps, notamment à partir de Mac OS X, dont la première version sort en 2001. L’une des plus importantes, la journalisation, est ainsi arrivée avec la mise à jour 10.2.2 fin 2002. Comme nous l’avons indiqué dans notre article sur NTFS, la journalisation est un élément important du stockage moderne, puisqu’il permet de suivre les modifications faites aux données et/ou métadonnées. C’est un facteur crucial de fiabilité du traitement de l’information, permettant de revenir à un état antérieur ou de retenter une opération ayant échoué.

C’est surtout Mac OS X 10.3 qui va apporter nombre de nouvelles possibilités, dont une journalisation par défaut des volumes formatés. Panther introduit également un gros changement structurel. Jusqu’à présent, les volumes HFS+ étaient encapsulés dans d’autres volumes HFS, pour des raisons de compatibilité. Mac OS 10.3 apporte une nouvelle version de HFS+ nommé HFSX, dont le formatage permet de se débarrasser de cette ancienne « encapsulation ».

Elle fournit aussi, pour la première fois, la sensibilité à la casse (les majuscules et minuscules sont prises en compte), sous forme optionnelle. Unicode 3.2 est aussi de la partie, et plusieurs mécanismes sont ajoutés pour réduire la fragmentation, qui devenait alors un sérieux problème.

Avec Tiger (Mac OS X 10.4), HFS+ est à nouveau enrichi, cette fois dans le domaine des permissions. Jusqu’à lors, le système des fichiers reprenait celles du monde Unix. Après la mise à jour, une nouvelle sécurité est ajoutée, basée sur les listes de contrôle d’accès (ACL). En plus de ces nouvelles capacités, l’ajout permet une simplification de la compatibilité dans les partages avec l’environnement Windows, puisque le NTFS s’appuie sur les ACL pour gérer les droits d’accès.

Par la suite, d’autres fonctions furent ajoutées, comme les liens physiques pour les dossiers dans Mac OS 10.5, la compression dans 10.6, ou encore le chiffrement des volumes dans 10.7.

Un système de fichiers très utilisé, mais pas sans reproche

[…]

Source et suite : nextinpact.com

=> Article complet : nextinpact.com <=

Newer is not always better

Le NTFS a d’abord été pensé pour le monde professionnel et a permis de repartir d’une page blanche. Aujourd’hui, il est presque partout. ReFS est, quant à lui, arrivé beaucoup plus tard. Conçu pour les serveurs, il est maintenant utilisable sur les ordinateurs classiques, bien qu’il ait une orientation spécifique.

Lire notre dossier sur les systèmes de fichiers :

| Qu’est-ce qu’un système de fichiers ? | Systèmes de fichiers : FAT12 à 32 et exFAT, conçus pour le grand public | Systèmes de fichiers : NTFS et ReFS, pensés d’abord pour l’entreprise | Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple | Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux Le NTFS, 30 ans déjà

NTFS est apparu en 1993 avec la première version de Windows NT, estampillée 3.1, en écho au Windows 3.1 classique déjà présent. NT signifiait « New Technology » et représentait les efforts développés par Microsoft pour proposer une base logicielle plus fiable et taillée pour le monde professionnel. NTFS signifie donc « New Technology File System ». Sa première version est ainsi apparue trois ans avant la FAT32.

Avec NTFS, l’organisation et la gestion des données sont complètement différentes. Dans les systèmes FAT, l’organisation se faisait ainsi via des tableaux hiérarchiques, tandis que l’allocation se faisait via une liste chainée de blocs. Une vision essentiellement séquentielle de l’information.

En NTFS, tout se fait en arbres B, une structure initialement créée chez Boeing pour faire face aux problèmes causés par la taille croissante des index de données. Depuis sa première version, NTFS se sert de tels arbres pour indexer les données au fur et à mesure. Un formatage en NTFS implique également un secteur d’amorçage (PBS), une Master File Table gardant une trace de l’intégralité des données, ainsi que des métafichiers servant à de multiples besoins, comme des informations sur le volume en cours.

Aujourd’hui, avec une taille de bloc par défaut de 4 ko, NTFS peut formater des volumes ou partitions d’un maximum de 16 To, correspondant aussi à la limite de taille d’un fichier. Ensuite, en doublant la taille de bloc, on double ces limites. On peut même définir des tailles de 256, 512, 1 024 ou 2 048 ko. Avec des blocs de 2 Mo, la limite de volume/partition et de fichier est de 8 Po, soit 8 000 To.

Il s’agit cependant d’une limite théorique. En effet, selon les fonctions que l’on souhaite utiliser, des volumes aussi gros ne sont pas recommandés, voire pas disponibles. Par exemple, si vous voulez continuer à vous servir de la fonction « Versions précédentes », la taille du volume ne pourra pas dépasser 64 To. Même chose pour les applications ayant besoin du service Volume Shadow Copy. De manière générale, Microsoft recommande d’adapter la taille de la partition selon la charge des usages et les performances que l’on veut obtenir.

Fonctionnalités : loin, très loin devant la FAT32

En matière de fonctions, le NTFS ne joue absolument pas dans la même cour que la FAT32. Leur orientation et leur conception sont très différentes, et le système de fichiers s’est largement enrichi avec les années et les versions. La plupart des fonctions que l’on connait sont apparues cependant avec Windows 2000 (NT5).

NTFS est ainsi un système journalisé, tenant compte de tous les changements intervenant sur le disque ou le volume. Cette journalisation est préemptive, signifiant que les nouvelles entrées sont inscrites dans le journal avant que les opérations sur les fichiers aient lieu. En conséquence, ces dernières peuvent être retentées ou annulées en cas de problème, sans pertes de données. Dans le cas d’un plantage par exemple, le système lit les journaux à la recherche d’opérations débutées et non terminées, pour corriger le tir.

Le service Volume Shadow Copy (VSS) est l’une des fonctions les plus importantes de NTFS. Elle permet la sauvegarde automatique ou manuelle de fichiers, de dossiers ou de volumes, même quand ils sont en cours d’utilisation, via la création d’instantanés. Initialement temporaires dans Windows XP, ces instantanés (snapshots) sont devenus persistants à partir de Windows Server 2003. Lorsque VSS travaille sur un lot de données, les entrées/sorties sont brièvement figées, le temps que les informations nécessaires à une reconstitution soient stockées ailleurs, sur le même disque ou un autre.

Les Access Control Lists (ACL) sont une autre fonction importante de NTFS. Ce sont elles qui définissent les autorisations d’accès, que ce soit pour un fichier ou un dossier. Elles peuvent être appliquées localement (par exemple en cas de comptes multiples sur un même ordinateur) ou pour le partage en réseau. On peut trouver facilement les ACL : dans l’onglet Sécurité de la fenêtre Propriétés d’un fichier ou dossier. On y verra alors la liste des utilisateurs ou groupes d’utilisateurs avec, pour chacun, les droits afférents. Exemple classique : les droits d’écriture pour la personne propriétaire d’un fichier, et de lecture uniquement pour les autres.

Chaque ACL se compose de plusieurs champs, dont le SID de l’utilisateur ou du groupe, le type Access définissant l’action (lire, écrire, exécuter, etc.) et le type ACE, qui autorise ou interdit cette action. En ligne de commande, CACLS (apparue avec Vista) permet aussi de modifier les autorisations d’un fichier ou dossier.

Quotas, chiffrement et compression

Les quotas sont une fonction classique des systèmes de fichiers « modernes ». Comme leur nom l’indique, ils permettent d’affecter une certaine quantité d’espace disque à chaque utilisateur d’une machine. Le système est souple et permet par exemple de mettre en place des alertes automatiques pour l’administrateur, d’augmenter les plafonds, de générer des rapports sur l’utilisation, etc.

Encrypting File System est une autre capacité apparue avec Windows 2000. Elle ajoute des capacités de chiffrement dans NTFS, pour les fichiers et dossiers. Il fonctionne main dans la main avec les ACL, mais permet d’aller plus loin en bloquant l’accès aux informations si une personne non autorisée utilise la machine. Il s’agit d’un chiffrement symétrique, dont la clé générale est elle-même chiffrée par une clé publique associée au propriétaire des données.

Le déchiffrement se produit quand cette clé publique et la clé privée de l’utilisateur sont associées. Pour chiffrer un fichier ou un dossier, faites un clic droit sur l’élément puis Propriétés. Dans l’onglet Général, cliquez sur Avancé et cochez la case « Chiffrer le contenu pour sécuriser les données ».

| Encrypted File System (EFS) : explorons les possibilités du système de chiffrement des fichiers sous Windows

NTFS

Notez qu’EFS est ancien et a été complété depuis plusieurs versions de Windows par un mécanisme supplémentaire, BitLocker. Arrivé avec Vista, il est dédié au chiffrement de partition ou intégral du disque et nécessite la présence d’une puce TPM 1.2 minimum dans l’ordinateur. Windows 10 et 11 Professionnel (ou Entreprise) le proposent systématiquement en fin d’installation, lors du premier démarrage. L’authentification de l’utilisateur (éventuellement via des facteurs multiples) est obligatoire pour déchiffrer les données. Bien que BitLocker s’appuie sur NTFS, il ne s’agit pas à proprement parler d’une de ses capacités.

NTFS contient aussi depuis longtemps un mécanisme de compression, qui n’est cependant plus guère utilisé aujourd’hui, depuis que l’espace de stockage est devenu beaucoup plus abordable. Cette compression (basée sur l’algorithme LZNT1, variante de Lempel-Ziv) est transparente et sans perte. Microsoft avait publié en 2016 certaines explications sur cette compression, notamment pourquoi le gain n’était en moyenne que de 25 %

Le mot-clé est « transparente », car les données présentées à l’utilisateur sont toujours sous leur forme décompressée, expliquant par exemple que l’empreinte (hash) d’un fichier compressé ne change pas. Les opérations sont en effet réalisées par le pilote à la volée. En conséquence, copier par exemple un fichier compressé vers une clé USB enverra la version décompressée. Pour compresser un fichier ou un dossier, il faut accéder au même panneau que précédemment et cocher la case « Compresser le contenu pour libérer de l’espace disque ».

NTFS supporte également d’autres fonctions plus spécifiques, comme des points de montage permettent de lier des volumes à des dossiers, ou encore un mode transactionnel que les applications peuvent exploiter pour renforcer l’intégrité des données pendant des manipulations particulières.

La défragmentation, c’est dépassé

[…]

Source et suite : nextinpact.com

à une époque on calculait cette différence, cela avait même un nom, le slack 😉

on voyait sur les forums une foules de gens demandant où était passé la différence de taille entre un dir /s et ce qu’il restait réellement sur le disque en dispo.

Je regrette aussi beaucoup le charme hypnotique du défragmenteur de W 98. Mais je me dis que ce qui avait un charme fou avec un DD de 200 Mo doit devenir un cauchemar total avec un DD de 6 To ! 😉